Telecommunications services provided over an IP Connectivity Access Network (IP-CAN) can be subject to charging and policy control mechanisms. This includes service-aware Quality of Service (QoS) control. Accordingly, some telecommunications systems incorporate Policy and Charging Control (PCC) architectures to provide this control. 3GPP TS 23.203 describes such a PCC architecture in respect of packet flows in an IP-CAN session established by a user terminal through an Evolved 3GPP telecommunications system, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. FIG. 1 illustrates schematically an example of the PCC architecture described in 3GPP TS 23.203 that comprises a Policy and Charging Enforcement Function (PCEF), a Policy and Charging rules Function (PCRF), an Application Function (AF), an Online Charging System (OCS), an Offline Charging System (OFCS) and the Subscription Profile Repository (SPR). The architecture can also include a Bearer Binding and Event Reporting Function (BBERF).
The PCRF is a functional element that encompasses policy control decision and flow based charging control functionalities, a combination of the functionality of the Policy Decision Function (PDF) and the Charging rule Function (CRF) defined in release 6 of the 3GPP specification. A PCRF can be implemented as a standalone node and behaves as a Policy Decision Point (PDP), or Policy Server (PS), that stores user data related to QoS enforcement, access control lists, etc. The PCRF provides policy and charging control for the media components negotiated between the user terminal and the AF. The PCRF receives session and media related information from the AF and informs the AF of traffic plane events. The PCRF also provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF can provision PCC rules and PCC decisions to the PCEF via the Gx reference point and to the BBERF through the Gxx reference point. The PCRF also forwards events between the BBERF, the PCEF, and the AF. Criteria such as the QoS subscription information may be used together with policy rules such as, service-based, subscription-based, or pre-defined PCRF internal policies to derive the authorized QoS to be enforced for a service data flow. The PCRF PCC decisions may be based on one or more of the following:                information obtained from the AF via the Rx reference point, e.g. the session, media and subscriber related information;        information obtained from the PCEF via the Gx reference point, e.g. IP-CAN bearer attributes, request type, subscriber related information and location information;        information obtained from the SPR via the Sp reference point, e.g. subscriber and service related data;        information pre-defined in the PCRF; and        information obtained from BBERF via the Gxa/Gxc (also referred to as Gxx) reference points.        
The PCEF is a functional entity that behaves as a Policy Enforcing Point (PEP) for enforcing decisions instructed by the PCRF and the OCS. The PCEF provides service data flow detection (based on service data flow filters defined in the PCC rules) to capture and analyse any user and signalling traffic, to identify the user and to capture details of the service(s) being used. The PCEF can then communicate this user and access-specific information to the PCRF over the Gx interface, to the OCS over the Gy interface and to the OFCS over the Gz interface. The PCEF enforces QoS control according to the QoS authorised by the PCRF. The PCEF is preferably co-located within the gateway node implementing the IP access to the PDN (PDN GW). As such, in a GPRS core network the PCEF is located within the GPRS Gateway Support Node (GGSN), whilst in the case of a CDMA2000 network the PCEF may be located in a Packet Data Serving Node (PDSN), and in a WLAN network the PCEF may be located in a Packet Data Gateway (PDG).
The OCS provides authorization for the usage of network resources based on the provisioned data and the user activity information it receives from PCEF. This authorization must be granted by the OCS prior to the actual resource usage. When receiving a network resource usage request, the network assembles the relevant charging information and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource usage authorization over the Gy interface. The resource usage authorization may be limited in its scope (e.g. volume of data or duration) therefore this authorization may have to be renewed from time to time as long as the user's resource usage persists. The OCS can support time, volume and event-based charging.
The AF is an element offering applications that require policy and/or charging control of the IP-CAN user plane behaviour. The AF communicates with the PCRF over the Rx interface to transfer dynamic session information (e.g. a description of the media to be delivered in the transport layer) required for PCRF decisions, as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events. One example of an AF is the P-CSCF of the IP Multimedia Core Network (IM CN) subsystem. In the case of a P-CSCF, the information communicated over the Rx interface is derived from the P-CSCF session information (e.g. SDP when SIP is used for signalling) and it mainly includes media components. A media component comprises a set of IP flows, each of which is described by a 5-tuple, the media type and required bandwidth. The AF can also subscribe to certain events that occur at the traffic plane level (i.e., events detected by either the PCEF or be BBERF). Those traffic plane events include events such as IP session termination or access technology-type change. When the AF has subscribed to a traffic plane event, the PCRF informs the AF of its occurrence.
The SPR contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level PCC rules by the PCRF. The Sp interface allows the PCRF to request subscription information related to the IP-CAN transport level policies from the SPR based on a subscriber ID and other IP-CAN session attributes.
The Evolved 3GPP telecommunications system provides support for different mobility protocols depending on which access technology is used. For 3GPP accesses (i.e. GERAN, UTRAN and E-UTRAN) the GPRS Tunnelling Protocol (GTP) or Proxy Mobile IPv6 (PMIPv6) can be used over the S5/S8 reference points. For Non-3GPP accesses it is possible to use Mobile IPv4 (MIPv4), Dual Stack MIPv6 (DSMIPv6) or PMIPv6 over the S2 reference point. These different protocols have different properties when it comes to how the bearers are implemented, and therefore place different requirements on the PCC architecture.
GTP not only carries mobility information but can also carry QoS, bearer signalling, etc. As such, when GTP is used between the Access Network GW (AN GW) (i.e. S-GW in a 3GPP access network) and the PDN-GW, the control signalling takes place over the same path as the user plane. This is therefore referred to as the ‘on-path’ model. The PCRF can therefore provide the authorised QoS information to the PCEF in the PDN GW over the Gx reference point. In contrast, mobile IP based protocols, such as MIP, PMIP or DSMIPv6, have not been designed to carry QoS information. As such, when one of these protocols is used between the AN GW and the PDN GW, the PCRF has to provide the authorised QoS information to a BBERF located in the AN GW over the Gxx reference point. This is therefore referred to as the ‘off-path’ mode, as the QoS signalling takes place on a path different to the user plane. The Gxx reference point represents the Gxa or Gxc reference points as applicable in each particular context. Gxc applies when the BBERF is located in the S-GW of a 3GPP access, whereas Gxa applies when the BBERF is located in a trusted non-3GPP access.
The BBERF supports a subset of the functions provided by the PCEF that includes bearer binding, uplink bearer binding verification and event reporting to the PCRF. Bearer binding is the association of a PCC rule and a QoS rule (if applicable) to an IP CAN bearer within that IP CAN session, and is performed by the Bearer Binding Function (BBF). The BBF is located at the PCEF if GTP is used as the mobility protocol towards the PCEF. Otherwise, where a mobile-IP based protocol, such as MIP, is used instead of GTP, the BBF is located at the BBERF. The QoS rules contain the information from the PCC rules that the BBERF requires to ensure that bearer binding can be performed. The QoS rules therefore contain the SDF template and precedence information, as well as the QoS information (e.g. QCI, bit rates etc). The PCRF provides the BBERF with the QoS rules derived from the PCC rules. The BBERF then enforces the QoS decisions by setting up the appropriate bearers.
The PCC architecture defined in 3GPP Release 8 supports roaming scenarios in which a subscriber can connect through a PDN GW in either the home network or in the visited network. However, control of enabled services and authorized resources are always handled by a PCRF in the subscriber's home network. The S9 reference point, between the home PCRF (H-PCRF) and a PCRF in the visited network (V-PCRF), has been defined in order to provide support for certain of these roaming scenarios. For those roaming scenarios in which the S9 reference point is used, the V-PCRF can reject policy decisions received from the home network, but cannot change them.
The two main roaming scenarios are home-routed access and visited access (also known as local breakout). In the home-routed access roaming scenario, an IP connection is established through a PDN GW in the home Public Land Mobile Network (H-PLMN). The PCEF connects (as usual) to the H-PCRF through Gx reference point, as illustrated schematically in FIG. 2. However, for certain scenarios, home-routed access may not be desired. For example, if the H-PLMN and the V-PLMN are geographically distant then it may be more suitable to use visited access. In visited access roaming, a PDN connection is established directly through a PDN GW in the V-PLMN, as illustrated schematically in FIG. 3.
According to current solutions the H-PCRF receives, from the AF, negotiated service information that will be used by the H-PCRF to determine the PCC rules that should apply for the AF session. These PCC rules include QoS parameters (bandwidth, QoS class Identifier, Allocation & Retention Priority) and optionally charging information. The H-PCRF then provides the PCC rules to the V-PCRF in the visited network. The V-PCRF then derives the QoS rules from the PCC rules, and sends the QoS rules to the GW (i.e. the PCEF in the PDN GW when GTP is used, or the BBERF in the AN GW when a MIP protocol is used). Upon receiving the QoS rules, the GW will proceed with the establishment of the appropriate bearer according to the provided QoS requirements. If there is a bearer already active that meets the QoS requirements, then that bearer will be modified instead of establishing a new bearer.
A problem arises when there is insufficient capacity to be allocated to a new data flow in the visited network. For example, a user is participating in a voice call and, at the same time, the user is browsing the internet over a visited LTE network. The user then decides that they want to add a streaming IPTV data flow. However, there is insufficient capacity available in the LTE network to support this service. In such circumstances there are currently three possible solutions, which are:                1. The AF (a streaming server in this case) can attempt to reinitiate the streaming data flow over another access.        2. The priority of an active data flow may be lowered to accommodate the new one. As a result of that, the previously active data flow might be dropped.        3. The AF may decide to reinitiate the streaming data flow by selecting a different codec that requires less bandwidth.        
The first two solutions attempt to solve the problem whilst still providing the same service, with same quality as that which was initially requested, either by opening a new access connection, using another available access, or dropping other data flows. Such solutions can be considered as “aggressive” since it is the conditions in the access network that are made to accommodate the new streaming data flow, as opposed to modifying the data flow to take account of these conditions. These approaches might not be suitable in situations where limited bandwidth is available.
In contrast, the third solution suggests that the new streaming data flow may be “downgraded” in order to that it may be more easily accommodated by the access network. One way to achieve this downgrading of the streaming data flow is through the use of transcoding equipment, at some point between the AF and the UE, to lower the quality of streaming data flow. However, this approach consumes a significant amount processing and introduces further complexity into the network architecture.
An alternative approach requires that an end-to-end negotiation of the codec must be performed. In other words, the AF and the UE must together select a codec that they both support, by means of an offer-answer negotiation. To do so the UE provides the AF with a list of codecs that it supports, and the AF then chooses one of those codecs for the streaming data flow. The AF informs the UE of the codec to be used and bearer allocation is attempted. However, the success or failure of the allocation depends on the available resources. As such, if the bearer allocation fails, the AF and the UE must once again perform codec negotiation, selecting a codec with an even lower bit rate. As such, according to this approach, the first codec negotiation will begin with the desired codec and, after every unsuccessful attempt, a subsequent negotiation will downgrade the codec to one requiring less bandwidth until an attempt succeeds. This trial-and-error approach generates additional traffic as several attempts might be required before bearer establishment is successful, with the number of attempts made depending on the codec set supported by AF and UE, and the intelligence in the AF to skip unnecessary attempts.